%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright by Olaf Kirch, okir@monad.swb.de   %
%                                                               %
% For copying conditions, please refer to the file COPYING.	%
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Issues of TCP/IP Networking}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% TCP/IP networking                                             %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip}
\index{TCP/IP|(}

We will now turn to the details you'll come in touch with when
connecting your \linux{} machine to a TCP/IP network including dealing
with IP~addresses, host names, and sometimes routing issues.  This
chapter gives you the background you need in order to understand what
your setup requires, while the next chapters will cover the tools to
deal with these.



 
\section{Networking Interfaces}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.interfaces}
\index{access network hardware|see {interface}}
\index{network!interface|see {interface}}
\index{interface}

To hide the diversity of equipment that may be used in a networking
environment, TCP/IP defines an abstract \emph{interface} through which
the hardware is accessed. This interface offers a set of operations
which is the same for all types of hardware and basically deals with
sending and receiving packets.


For each periphereal device you want to use for networking, a
corresponding interface has to be present in the kernel. For example,
Ethernet interfaces in \linux{} are called \file{eth0} and \file{eth1},
and SLIP interfaces come as \file{sl0}, \file{sl1}, etc.  These
interface names are used for configuration purposes when you want to
name a particular physical device to the kernel. They have no meaning
beyond that.


To be useable for TCP/IP networking, an interface must be assigned an
IP~address which serves as its identifcation when communicating with the
rest of the world. This address is different from the interface name
mentioned above; if you compare an interface to door, then the address
is like the name-plate pinned on it.


Of course, there are other device parameters that may be set; one of
these is the maximum size of datagrams that can be processed by that
particular piece of hardware, also called \emph{Maximum Transfer Unit},
or MTU. Other attributes will be introduced later.


\section{IP Addresses}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.ip-addresses}
\index{IP!networks}
\index{IP!address|(}

As mentioned in the previous chapter, the addresses understood by the
IP~networking protocol are 32-bit numbers. Every machine must be assigned a
number unique to the networking environment. If you are running
a local network that does not have TCP/IP traffic with other 
networks, you may assign these numbers according to your personal
preferences. However, for sites on the Internet, numbers are
assigned by a central authority, the Network Information Center,
or NIC.\footnote{
 Frequently, IP~addresses will be assigned to you by the provider you
 buy your IP~connectivity from. However, you may also apply to
 NIC directly for an IP address for your network by sending a mail to
 \email{hostmaster@internic.net}.
}


\index{dotted quad}
For easier reading, IP addresses are split up into four 8~bit numbers
called \emph{octets}.  For example, \host{quark.physics.groucho.edu} has an
IP~address of \host{0x954C0C04}, which is written as \host{149.76.12.4}.
This format is often referred to as the \emph{dotted quad notation}.


Another reason for this notation is that IP~addresses are split into a
\emph{network} number, which is contained in the leading octets, and a
\emph{host} number, which is the remainder.  When applying to the NIC
for IP~addresses, you are not assigned an address for each single host
you plan to use. Instead, you are given a network number, and are
allowed to assign all valid IP~addresses within this range to hosts on
your network according to your preferences.


Depending on the size of the network, the host part may need to be
smaller or larger. To accomodate different needs, there are several
classes of networks, defining different splits of IP~addresses.


\begin{dispitems}
\ditem[Class A]
        Class A comprises networks \host{1.0.0.0} through
        \host{127.0.0.0}.  The network number is contained in the first
        octet.  This provides for a 24~bit host part, allowing roughly
        1.6 million hosts.

\ditem[Class B]
        Class B contains networks \host{128.0.0.0} through
        \host{191.255.0.0}; the network number is in the first two
        octets.  This allows for 16320 nets with 65024 hosts each.

\ditem[Class C]
        Class C networks range from \host{192.0.0.0} through
        \host{223.255.255.0}, with the network number being contained in
        the first three octets. This allows for nearly 2~million
        networks with up to 254 hosts.

\ditem[Classes D, E, and F]
        Addresses falling into the range of \host{224.0.0.0} through
        \host{254.0.0.0} are either experimental, or are reserved for
        future use and don't specify any network.

\end{dispitems}


If we go back to the example in the previous chapter, we find that
\host{149.76.12.4}, the address of \host{quark}, refers to host
\host{12.4} on the class~B network \host{149.76.0.0}.


\index{address!broadcast}
You may have noticed that in the above list not all possible values were
allowed for each octet in the host part. This is because host numbers
with octets all \host{0} or all \host{255} are reserved for special purposes.
An address where all host part bits are zero refers to the network, and
one where all bits of the host part are 1 is called a broadcast address.
This refers to all hosts on the specified network simultaneously.
Thus, \host{149.76.255.255} is not a valid host address, but refers
to all hosts on network \host{149.76.0.0}.


\index{IP!default route}
\index{default IP route|see {route, default}}
\index{route, default}
\index{loopback!address}
There are also two network addresses that are reserved, \host{0.0.0.0} and
\host{127.0.0.0}. The first is called the \emph{default route}, the latter
the \emph{loopback address}. The default route has something to do with the
way IP routes datagrams, which will be dealt with below.


Network \host{127.0.0.0} is reserved for IP traffic local to your
host.  Usually, address \host{127.0.0.1} will be assigned to a special
interface on your host, the so-called \emph{loopback interface}, which
acts like a closed circuit. Any IP packet handed to it from TCP or UDP
will be returned to them as if it had just arrived from some network.
This allows you to develop and test networking software without ever
using a ``real'' network. Another useful application is when you want
to use networking software on a standalone host. This may not be as
uncommon as it sounds; for instance, many UUCP sites don't have IP
connectivity at all, but still want to run the INN news system
nevertheless. For proper operation on \linux{}, INN requires the
loopback interface.


\index{IP!address|)}


\section{Address Resolution}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.arp}
\index{Address Resolution Protocol|see {ARP}}
\index{Reverse Address Resolution Protocol|see {RARP}}
\index{ARP|(}
\index{Ethernet!address}

Now that you've seen how IP~addresses are made up, you may be wondering
how they are used on an Ethernet to address different hosts. After all,
the Ethernet protocol identifies hosts by a six-octet number that has
absolutely nothing in common with an IP~address, doesn't it?


\index{ham radio}
Right. That's why a mechanism is needed to map IP~addresses onto
Ethernet addresses. This is the so-called \emph{Address Resolution
Protocol}, or ARP. In fact, ARP is not confined to Ethernets at all,
but is used on other types networks such as ham radio as well.  The
idea underlying ARP is exactly what most people do when they have to
find Mr.~X.~Ample in a throng of 150~people: they go round, calling
out his name, confident that he will respond if he's there.


When ARP wants to find out the Ethernet address corresponding to a
given IP~address, it uses a feature of Ethernet known as
``broadcasting,'' where a datagram is addressed to all stations on the
network simultaneously. The broadcast datagram sent by ARP contains a
query for the IP~address. Each receiving host compares this to its own
IP~address, and if it matches, returns an ARP reply to the inquiring
host. The inquiring host can now extract the sender's Ethernet address
from the reply.


Of course you might wonder how a host may know on which of the
zillions of Ethernets throughout the world it is to find the desired
host, and why this should even be an Ethernet. These questions all
involve what is called routing, namely finding out the physical
location of a host in a network.  This will be the topic of the
following section.


For a moment, let's talk about ARP a little longer. Once a host has
discovered an Ethernet address, it stores it in its ARP cache,
so that it doesn't have to query for it the next time it wants to
send a datagram to the host in question. However, it is unwise to
keep this information forever; for instance, the remote host's
Ethernet card may be replaced because of technical problems, so the 
ARP entry becomes invalid. To force another query for the IP~address,
entries in the ARP cache are therefore discarded after some time.


\index{diskless clients}
\index{BOOTP}
\index{RARP}
Sometimes, it is also necessary to find out the IP~address associated
with a given Ethernet address. This happens when a diskless machine
wants to boot from a server on the network, which is quite a common
situation on local area networks. A diskless client, however, has
virtually no information about itself~-- except for its Ethernet
address! So what it basically does is broadcast a message containing a
plea for boot servers to tell it its IP~address. There's another
protocol for this, named \emph{Reverse Address Resolution Protocol}, or
RARP. Along with the BOOTP protocol, it serves to define a procedure
for bootstrapping diskless clients over the network.


\index{ARP|)}

\section{IP Routing}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing}
\index{IP!routing|(}

\subsection{IP Networks}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.networks}
\index{IP!networks}

\blackdiamond
When you write a letter to someone, you usually put a complete address
on the envelope, specifying the country, state, zip code, etc. After
you put it into the letter box, the postal service will deliver it to
its destination: it will be sent to the country indicated, whose national
service will dispatch it to the proper state and region, etc.  The
advantage of this hierarchical scheme is rather obvious: Wherever you
post the letter, the local postmaster will know roughly the direction to
forward the letter to, but doesn't have to care which way the letter
will travel by within the destination country.


IP~networks are structured in a similar way. The whole Internet
consists of a number of proper networks, called \emph{autonomous systems}.
Each such system performs any routing between its member hosts
internally, so that the task of delivering a datagram is reduced to finding
a path to the destination host's network. This means, as soon as the datagram 
is handed to \emph{any} host that is on that particular network, further 
processing is done exclusively by the network itself.


\subsection{Subnetworks}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.subnets}
\index{IP!sub-networks|see {IP, subnet}}
\index{IP!subnet|(}

This structure is reflected by splitting IP~addresses into a host and
network part, as explained above. By default, the destination network is
derived from the network part of the IP~address. Thus, hosts with
identical IP~network numbers should be found within the same network,
and vice versa.\footnote{
 Autonomous systems are slightly more general, however. They may comprise
 more than one IP~network.
}


It makes sense to offer a similar scheme \emph{inside} the network,
too, since it may consist of a collection of hundreds of smaller
networks itself, with the smallest units being physical networks like
Ethernets. Therefore, IP allows you to subdivide an IP~network into
several \emph{subnets}.


\index{interface!netmask}
\index{IP!netmask}
A subnet takes over responsibility for delivering datagrams to a certain
range of IP~addresses from the IP~network it is part of.  As with
classes A, B, or C, it is identified by the network part of the
IP~addresses. However, the network part is now extended to include
some bits from the host part.  The number of bits that are interpreted
as the subnet number is given by the so-called \emph{subnet mask}, or
\emph{netmask}.  This is a 32~bit number, too, which specifies the bit
mask for the network part of the IP~address.


\begin{figure}[htbp]
\iftex
 \ifps
  \begin{center}
   \mbox{\epsffile{figures/subnet.epsf}}
  \end{center}
 \else
  \begin{center}
   \input{subnet.eepic}
  \end{center}
 \fi
\else
\fi
 \caption{
  \label{tcpip.fig.subnet}
  Subnetting a class B network
 }
\end{figure}


\index{Groucho Marx University}
The campus network of Groucho Marx University is an example of such a
network. It has a class~B network number of \host{149.76.0.0}, and its
netmask is therefore \host{255.255.0.0}.
% It is connected to the Internet
% through a single host at the GCC Groucho Computing Centre, so all
% datagram from the outside pass this gateway machine.


Internally, GMU's campus network consists of several smaller networks,
such as the LANs of various departments. So the range of IP~addresses
is broken up into 254 subnets, \host{149.76.1.0} through
\host{149.76.254.0}.  For example, the Department of Theoretical
Physics has been assigned \host{149.76.12.0}.  The campus backbone is
a network by its own right, and is given \host{149.76.1.0}.  These
subnets share the same IP~network number, while the third octet is
used to distinguish between them.  Thus they will use a subnet mask of
\host{255.255.255.0}.


Figure \ref{tcpip.fig.subnet} shows how \host{149.76.12.4}, the
address of \host{quark}, is interpreted differently when the address
is taken as an ordinary class~B network, and when used with
subnetting.



\index{delegating!IP subnets}
\index{subnet (IP)}
It is worth noting that subnetting (as the technique of generating
subnets is called) is only an \emph{internal division} of the network.
Subnets are generated by the network owner (or the administrators).
Frequently, subnets are created to reflect existing boundaries, be they
physical (between two Ethernets), administrative (between two
departments), or geographical, and authority over these subnets is
delegated to some contact person. However, this structure affects only
the network's internal behavior, and is completely invisible to the
outside world.

\index{IP!subnet|)}

\subsection{Gateways}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.gateway}
\index{internetworking}
\index{gateway|(}

Subnetting is not only an organizational benefit, it is frequently a
natural consequence of hardware boundaries.  The viewpoint of a host on
a given physical network, such as an Ethernet, is a very limited one:
the only hosts it is able to talk to directly are those of the network
it is on.  All other hosts can be accessed only through so-called
\emph{gateways}.  A gateway is a host that is connected to two or more
physical networks simultaneously and is configured to switch packets
between them.


For IP to be able to easily recognize if a host is on a local physical
network, different physical networks have to belong to different
IP~networks. For example the network number \host{149.76.4.0} is
reserved for hosts on the mathematics LAN. When sending a datagram to
\host{quark}, the network software on \host{erdos} immediately sees from
the IP~address, \host{149.76.12.4}, that the destination host is on a
different physical network, and therefore can be reached only through
a gateway (\host{sophus} by default).


\host{sophus} itself is connected to two distinct subnets: the
Mathematics Department, and the campus backbone. It accesses each
through a different interface, \file{eth0} and \file{fddi0},
respectively.  Now, what IP~address do we assign it? Should we give it
one on subnet \host{149.76.1.0}, or on \host{149.76.4.0}?


The answer is: both. When talking to a host on the Maths LAN,
\host{sophus} should use an IP~address of \host{149.76.4.1}, and when
talking to a host on the backbone, it should use \host{149.76.1.4}.


Thus, a gateway is assigned one IP~address per network it is on.  These
addresses~--- along with the corresponding netmask~--- are tied to the
interface the subnet is accessed through. Thus, the mapping of
interfaces and addresses for \host{sophus} would look like this:

\begin{center}
\begin{tabular}{|l|r|r|}
 \hline
 iface		& address		& netmask		\\
 \hline\hline
 \file{eth0}	& \host{149.76.4.1}	& \host{255.255.255.0}	\\
 \file{fddi0}	& \host{149.76.1.4}	& \host{255.255.255.0}	\\
 \file{lo}	& \host{127.0.0.1}	& \host{255.0.0.0}	\\
 \hline
\end{tabular}
\end{center}

The last entry describes the loopback interface \file{lo}, which was
introduced above.


Figure~\ref{intro.fig.ip} shows a part of the network topology at
Groucho Marx University (GMU).  Hosts that are on two subnets at the
same time are shown with both addresses.

\begin{figure}[htbp]
\iftex
 \ifps
  \begin{center}
   \mbox{\epsffile{figures/groucho.epsf}}
  \end{center}
 \else
  % \font\egttt=cmtt8
  % \font\twltt=cmtt12
  % \font\sevrm=cmr7
  % \font\tenit=cmti10
  \begin{center}
   \input{groucho.eepic}
  \end{center}
 \fi
\else
%% This node includes an ASCII Version of the above GMU picture for texinfo.
 \verbinclude{groucho.ascii}
\fi
 \caption{
  \label{intro.fig.ip}
  A part of the net topology at Groucho Marx Univ.
 }
\end{figure}


Generally, you can ignore the subtle difference between attaching an
address to a host or its interface. For hosts that are on one network
only, like \host{erdos}, you would generally refer of the host as
having this-and-that IP~address although strictly speaking, it's the Ethernet
interface that has this IP~address. However, this distinction is only
really important when you refer to a gateway.


% Frequently, this involves splitting an existing subnet even further.
% For example, the Mathemeatics Department runs two Ethernets that are
% joined by the gateway that also provides the link to the FDDI campus
% backbone. To be able to perform routing between these, the network
% \host{149.76.4.0} is subdivided into two sub-subnets of 126 hosts
% each. The netmask for these is \host{255.255.255.128}, and hosts
% on each Ethernet have addresses from the ranges \host{149.76.4.1}
% through \host{149.76.4.127}, and \host{149.76.4.129}
% through \host{149.76.4.254}, respectively.

\index{gateway|)}

\subsection{The Routing Table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.table}
\index{IP!routing}
\index{IP!routing table}
\index{routing!table}

We are now focusing our attention on how IP chooses a gateway to use
when delivering a datagram to a remote network.


We have seen before that \host{erdos}, when given a datagram for
\host{quark}, checks the destination address and finds it is not on the
local network. It therefore sends it to the default gateway,
\host{sophus}, which is now basically faced with the same task.
\host{sophus} recognizes that \host{quark} is not on any of the networks
it is connected to directly, so it has to find yet another gateway to
forward it through. The correct choice would be \file{niels}, the
gateway to the Physics Department. \host{sophus} therefore needs some
information to associate a destination network with a suitable gateway.


The routing information IP uses for this is basically a table linking
networks to gateways that reach them. A catch-all entry (the \emph{default
route}) must generally be supplied, too; this is the gateway associated
with network \host{0.0.0.0}. All packets to an unknown network are sent
through the default route.  On \host{sophus}, this table might look like
this:


\begin{center}
 \begin{tabular}{|l|l|l|}
  \hline
  Network               & Gateway               & Interface	\\
  \hline\hline
  \host{149.76.1.0}     & -		        & \host{fddi0}	\\
  \host{149.76.2.0}     & \host{149.76.1.2}     & \host{fddi0}	\\
  \host{149.76.3.0}     & \host{149.76.1.3}     & \host{fddi0}	\\
  \host{149.76.4.0}     & -                     & \host{eth0}	\\
  \host{149.76.5.0}     & \host{149.76.1.5}     & \host{fddi0}	\\
  \ldots                & \ldots             	& \ldots	\\
  \host{0.0.0.0}        & \host{149.76.1.2}     & \host{fddi0}	\\
  \hline
 \end{tabular}
\end{center}


Routes to a network that \host{sophus} is directly connected to don't
require a gateway; therefore they show a gateway entry of ``-''.


\index{IP!dynamic routing}
\index{dynamic routing}
\index{routing!daemon}
\index{routing!dynamic}
Routing tables may be built by various means. For small LANs, it is
usually most efficient to construct them by hand and feed them to IP
using the \prog{route} command at boot time (see chapter~\ref{iface}).
For larger networks, they are built and adjusted at run-time by
\emph{routing daemons}; these run on central hosts of the network and
exchange routing information to compute ``optimal'' routes between the
member networks.


\index{IP!routing protocols}
\index{routing!protocols}
\index{Routing Information Protocol}
\index{RIP|see {Routing Information Protocol}}
\index{routed@\prog{routed}}
\index{gated@\prog{gated}}
Depending on the size of the network, different routing protocols will
be used.  For routing inside autonomous systems (such as Groucho Marx
campus), the \emph{internal routing protocols} are used.  The most
prominent one is RIP, the Routing Information Protocol, which is
implemented by the BSD \prog{routed} daemon.  For routing between
autonomous systems, \emph{external routing protocols} like EGP
(External Gateway Protocol), or BGP (Border Gateway Protocol) have to be
used; these (as well as RIP) have been implemented in the University of
Cornell's \prog{gated} daemon.\footnote{
 \prog{routed} is considered broken by many people.  Since \prog{gated}
 supports RIP  as well, it is better to use that instead.
}


% Usually, you won't need any dynamic routing unless your network is very
% large, or richly interconnected.  For this reason, only static routing
% tables created at boot time will be discussed in this book.



\subsection{Metric Values}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.metric}
\index{Routing Information Protocol}
\index{IP!metric}
\index{routing!metric}
\index{metric, routing|see {routing, metric}}

Dynamic routing based on RIP chooses the best route to some destination
host or network based on the number of ``hops'', that is, the gateways a
datagram has to pass before reaching it. The shorter a route is, the
better RIP rates it. Very long routes with 16 or more hops are regarded
as unusable, and are discarded.


To use RIP to manage routing information internal to your local
network, you have to run \prog{gated} on all hosts. At boot time,
\prog{gated} checks for all active network interfaces.  If there is
more than one active interface (not counting the loopback interface),
it assumes the host is switching packets between several networks, and
will actively exchange and broadcast routing information. Otherwise,
it will only passively receive any RIP updates and update the local
routing table.


When broadcasting the information from the local routing table,
\prog{gated} computes the length of the route from the so-called
\emph{metric value} associated with the routing table entry. This
metric value is set by the system administrator when configuring the
route and should reflect the actual cost of using this route. Therefore,
the metric of a route to a subnet the host is directly connected to
should always be zero, while a route going through two gateways should
have a metric of two. However, note that you don't have to bother about
metrics when you don't use \prog{RIP} or \prog{gated}.

\index{IP!routing|)}

\section{The Internet Control Message Protocol}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.icmp}
\index{Internet Control Message Protocol}
\index{ICMP}

\index{ICMP!Port Unreachable}
IP has a companion protocol that we haven't talked about yet. This is
the \emph{Internet Control Message Protocol} (ICMP) and is used by the
kernel networking code to communicate error messages and the like to
other hosts. For instance, assume that you are on \host{erdos} again and
want to \prog{telnet} to port 12345 on \host{quark}, but there's no
process listening on that port. When the first TCP packet for this port
arrives on \host{quark}, the networking layer will recognize this and
immediately return an ICMP message to \host{erdos} stating ``Port
Unreachable''.


\index{ICMP!Redirect}
\index{routing!ICMP Redirect}
\index{routing!dynamic}
\index{IP!routing}
There are quite a number of messages ICMP understands, many of which
deal with error conditions. However, there is one very interesting
message called the Redirect message. It is generated by the routing
module when it detects that another host is using it as a gateway,
although there is a much shorter route. For example, after booting the
routing table of \host{sophus} may be incomplete, containing the routes
to the Mathematics network, to the FDDI backbone, and the default route
pointing at the Groucho Computing Center's gateway (\host{gcc1}).
Therefore, any packets for \host{quark} would be sent to \host{gcc1}
rather than to \host{niels}, the gateway to the Physics Department. When
receiving such a datagram, \host{gcc1} will notice that this is a poor
choice of route, and will forward the packet to \host{niels}, at the
same time returning an ICMP Redirect message to \host{sophus} telling it
of the superior route.


Now, this seems a very clever way to avoid having to set up any but
the most basic routes manually. However be warned that relying on
dynamic routing schemes, be it RIP or ICMP Redirect messages, is not
always a good idea. ICMP Redirect and RIP offer you little or no
choice in verifying that some routing information is indeed authentic.
This allows malicious good-for-nothings to disrupt your entire network
traffic, or do even worse things.  For this reason, there are some
versions of the \linux{} networking code that treat Redirect messages
that affect network routes, as if they were only Redirects for host
routes.

\index{TCP/IP|)}


\section{The Domain Name System}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns}
\index{DNS|(}
\index{Domain Name System|see {DNS}}

\subsection{Hostname Resolution}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.resolv}
\index{hostname!resolution}
\index{hostname!mapping to addresses}
\index{IP!address!and hostname}

\blackdiamond
As described above, addressing in TCP/IP networking revolves around
32~bit numbers. However, you will have a hard time remembering more than
a few of these. Therefore, hosts are generally known by ``ordinary''
names such as \host{gauss} or \host{strange}. It is then the
application's duty to find the IP~address corresponding to this name.
This process is called \emph{host name resolution}.


An application that wants to find the IP~address of a given host name
does not have to provide its own routines for looking up a hosts and
IP~adresses. Instead, it relies on number of library functions that do
this transparently, called \func{gethostbyname(3)} and
\func{gethostbyaddr(3)}. Traditionally, these and a number of related
procedures were grouped in a separate library called the resolver
library; on \linux{}, these are part of the standard \file{libc}.
Colloquially, this collection of functions are therefore referred to as
``the resolver''.


Now, on a small network like an Ethernet, or even a cluster of them, it
is not very difficult to maintain tables mapping host names to
addresses.  This information is usually kept in a file named
\file{/etc/hosts}.  When adding or removing hosts, or reassigning
addresses, all you have to do is update the \file{hosts} on all hosts.
Quite obviously, this will become burdensome with networks than comprise
more than a handful of machines.


One solution to this problem is NIS, the \emph{Network Information
System} developed by Sun Microsystems, colloquially called YP, or
\emph{Yellow Pages}. NIS stores the \file{hosts} file (and other
information) in a database on a master host, from which clients may
retrieve it as needed. Still, this approach is only suitable for
medium-sized networks such as LANs, because it involves maintaining
the entire \file{hosts} database centrally, and distributing it to all
servers.


On the Internet, address information was initially stored in a single
\file{HOSTS.TXT} database, too. This file was maintained at the Network
Information Center, or NIC, and had to be downloaded and installed by
all participating sites. When the network grew, several problems with
this scheme arose. Beside the administrative overhead involved in
installing \file{HOSTS.TXT} regularly, the load on the servers that
distributed it became too high. Even more severe was the problem that
all names had to be registered with the NIC, which had to make sure that
no name was issued twice.


This is why, in 1984, a new name resolution scheme has been adopted, 
the \emph{Domain Name System}. DNS was designed by Paul Mockapetris,
and addresses both problems simultaneously.


\subsection{Enter DNS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.bind}
\index{name space (DNS)}
\index{hostname!fully qualified}
\index{hostname!and domain name}
\index{domain name|(}

DNS organizes host names in a hierarchy of domains.  A domain is a
collection of sites that are related in some sense~--- be it because
they form a proper network (e.g. all machines on a campus, or all hosts
on BITNET), because they all belong to a certain organization (like the
U.S. government), or because they're simply geographically close. For
instance, universities are grouped in the \host{edu} domain, with each
University or College using a separate \emph{subdomain} below which
their hosts are subsumed. Groucho Marx University might be given the
\host{groucho.edu} domain, with the LAN of the Mathematics Department
being assigned \host{maths.groucho.edu}.  Hosts on the departmental
network would have this domain name tacked onto their host name; so
\host{erdos} would be known as \host{erdos.maths.groucho.edu}.  This is
called the \emph{fully qualified domain name}, or FQDN, which uniquely
identifies this host world-wide.


\begin{figure}[htb]
\iftex
 \ifps
  \begin{center}
   \mbox{\epsffile{figures/dns.epsf}}
  \end{center}
 \else
  \font\nintt=cmtt9
  \input{dns.eepic}
 \fi
\else
 \verbinclude{dns.ascii}
\fi
 \caption{
  \label{intro.fig.dns}
  A part of the domain name space
 }
\end{figure}


Figure~\ref{intro.fig.dns} shows a section of the name space.  The entry
at the root of this tree, which is denoted by a single dot, is quite
appropriately called the \emph{root domain}, and encompasses all other
domains. To indicate that a host name is a fully qualified domain name,
rather than a name relative to some (implicit) local domain, it is
sometimes written with a trailing dot. This signifies that the name's
last component is the root domain.


\index{domains!top-level}
Depending on its location in the name hierarchy, a domain may be
called top-level, second-level, or third-level. More levels of
subdivision occur, but are rare. These are a couple of top-level
domains you may see frequently:

\medskip
\begin{dispitems}
\ditem[\host{edu}]
        (Mostly US) educational institutions like universities, etc.

\ditem[\host{com}]
        Commercial organizations, companies.

\ditem[\host{org}]
        Non-commercial organizations. Often private UUCP networks
        are in this domain.

\ditem[\host{net}]
        Gateways and other administrative host on a network.

\ditem[\host{mil}]
	US military institutions.

\ditem[\host{gov}]
	US government institutions.

\ditem[\host{uucp}]
        Officially, all site names formerly used as UUCP names
        without domain, have been moved to this domain.

\end{dispitems}


Technically, the first four of these belong to the US part of the
Internet, but you may also see non-US sites in these domains. This is
especially true of the \host{net} domain.  However, \host{mil}
and \host{gov} are used exclusively in the US.


Outside the US, each country generally uses a top-level domain of its
own named after the two-letter country code defined in ISO-3166.
Finland, for instance, uses the \host{fi} domain, \host{fr} is used by
France, \host{de} by Germany, or \host{au} by Australia etc.  Below
this top-level domain, each country's NIC is free to organize host
names in whatever way they want. Australia, for example, has
second-level domain similar to the international top-level domains,
named \host{com.au}, \host{edu.au}, and so on.  Others, like Germany,
don't use this extra level, but rather have slightly longish names that
refer directly to the organizations running a particular domain. For
example, it's not uncommon to see host names like
\host{ftp.informatik.uni-erlangen.de}. Chalk that up to German
efficiency.


Of course, these national domains do not imply that a host below that
domain is actually located in that country; it only signals that the
host has been registered with that country's NIC. A Swedish manufacturer
might have a branch in Australia, and still have all its hosts
registered with the \host{se} top-level domain.


Now, organizing the name space in a hierarchy of domain names nicely
solves the problem of name uniqueness; with DNS, a host name has to be
unique only within its domain to give it a name different from all
other hosts world-wide. Furthermore, fully qualified names are quite
easy to remember.  Taken by themselves, these are already very good
resaons to split up a large domain into several subdomains.


\index{delegating!DNS subdomains}
\index{creating!subdomains}
\index{subdomain (DNS)}
But DNS does even more for you than than this: it allows you to delegate
authority over a subdomain to its administrators.  For example, the
maintainers at the Groucho Computing Center might create a subdomain for
each department; we already encountered the \host{maths} and
\host{physics} subdomains above.  When they find the network at the
Physics Department too large and chaotic to manage from outside (after
all, physicists are known to be an unruly bunch of people), they may
simply pass control over the \host{physics.groucho.edu} domain to the
administrators of this network.  These are then free to use whatever
host names they like, and assign them IP addresses from their network in
whatever fashion the like, without outside interference.


\index{DNS!zone}
\index{zone, DNS|see {DNS, zone}}
To this end, the name space is split up into \emph{zones}, each rooted
at a domain. Note the subtle difference between a zone and a domain:
the \emph{domain} \host{groucho.edu} encompasses all hosts at the
Groucho Marx University, while the \emph{zone} \host{groucho.edu}
includes only the hosts that are managed by the Computing Center
directly, for example those at the Mathematics Department.  The hosts
at the Physics Department belong to a different zone, namely
\host{physics.groucho.edu}.  In figure~\ref{intro.fig.dns}, the start
of a zone is marked by a small circle to the right of the domain name.


\index{domain name|)}

\subsection{Name Lookups with DNS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.lookups}
\index{hostname!lookup}
\index{DNS!lookup}

At first glance, all this domain and zone fuss seems to make name
resolution an awfully complicated business. After all, if no central
authority controls what names are assigned to which hosts, then how is a
humble application supposed to know?!


Now comes the really ingenuous part about DNS. If you want to find
out the IP~address of \host{erdos}, then, DNS says, go ask the people
that manage it, and they will tell you.


\index{name server|(}
In fact, DNS is a giant distributed database. It is implemented by means
of so-called name servers that supply information on a given domain or
set of domains. For each zone, there are at least two, at most a few,
name servers that hold all authoritative information on hosts in that
zone. To obtain the IP~address of \host{erdos}, all you have to do is
contact the name server for the \host{groucho.edu} zone, which will then
return the desired data.


%% ...orig: In order that you don't have to rely on magic...

\index{DNS!query}
\index{DNS!zone}
Easier said than done, you might think. So how do I know how to reach
the name server at Groucho Marx University? In case your computer isn't
equipped with an address-resolving oracle, DNS provides for this, too.
When your application wants to look up information on \host{erdos}, it
contacts a local name server, which conducts a so-called iterative query
for it.  It starts off by sending a query to a name server for the root
domain, asking for the address of \host{erdos.maths.groucho.edu}. The root
name server recognizes that this name does not belong to its zone of
authority, but rather to one below the \host{edu} domain. Thus, it tells
you to contact an \host{edu} zone name server for more information, and
encloses a list of all \host{edu} name servers along with their addresses.
Your local name server will then go on and query one of those, for instance
\host{a.isi.edu}.  In a manner similar to the root name server,
\host{a.isi.edu} knows that the \host{groucho.edu} people run a zone of
their own, and point you to their servers. The local name server will then
present its query for \host{erdos} to one of these, which will finally
recognize the name as belonging to its zone, and return the corresponding
IP~address.


Now, this looks like a lot of traffic being generated for looking up a
measly IP~address, but it's really only miniscule compared to the amount
of data that would have to be transferred if we were still stuck with
\file{HOSTS.TXT}. But there's still room for improvement with this
scheme.

% Commonly the resolver library, instead of conducting the DNS
% query itself, will delegate it to a name server running on the local
% network. This server will perform the DNS lookup as described above, and
% return the result to the application.


To improve response time during future queries, the name server will
store the information obtained in its local \emph{cache}.  So the next
time anyone on your local network wants to look up the address of a
host in the \host{groucho.edu} domain, your name server will not have
to go through the whole process again, but will rather go to the
\host{groucho.edu} name server directly.\footnote{
 If it didn't, then DNS would be about as bad as any other method,
 because each query would involve the root name servers.
}


\index{DNS!time to live}
\index{DNS!ttl|see {DNS, time to live}}
Of course, the name server will not keep this information forever, but
rather discard it after some period. This expiry interval is called the
\emph{time to live}, or TTL. Each datum in the DNS database is assigned
such a TTL by administrators of the responsible zone.



\subsection{Domain Name Servers}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.servers}
\index{authoritative name server}
\index{name server!authoritative}
\index{DNS!zone}

Name servers that hold all information on hosts within a zone are
called \emph{authoritative} for this zone, and are sometimes referred
to as \emph{master name servers}. Any query for a host within this
zone will finally wind down at one of these master name servers.


\index{synchronizing name servers}
\index{name server!synchronizing}
\index{name server!secondary}
\index{name server!primary}
To provide a coherent picture of a zone, its master servers must be
fairly well synchronized. This is achieved by making one of them the
\emph{primary} server, which loads its zone information from data
files, and making the others \emph{secondary} servers who transfer the
zone data from the primary server at regular intervals.


One reason to have several name servers is to distribute work load,
another is redundance. When one name server machine fails in a benign
way, like crashing or losing its network connection, all queries will
fall back to the other servers. Of course, this scheme doesn't protect
you from server malfunctions that produce wrong replies to all DNS
requests, e.g. from software bugs in the server program itself.


\index{name server!caching-only}
Of course, you can also think of running a name server that is not
authoritative for any domain.\footnote{
 Well, almost. A name server at least has to provide name service
 for \host{localhost} and reverse lookups of \host{127.0.0.1}.
} This type of server is useful nevertheless, as it is still able to
conduct DNS queries for the applications running on the local network,
and cache the information. It is therefore called a \emph{caching-only}
server.


\index{name server|)}

\subsection{The DNS Database}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.records}
\index{DNS!database}

We have seen above that DNS does not only deal with IP~addresses of
hosts, but also exchanges information on name servers.  There are in
fact a whole bunch of different types of entries the DNS database may
have.


\index{DNS!resource record}
\index{DNS!RR|see {DNS, resource record}}
\index{resource record|see {DNS, resource record}}
\index{RR|see {DNS, resource record}}
A single piece of information from the DNS database is called a
\emph{resource record}, or RR for short. Each record has a type
associated with it, describing the sort of data it represents, and a
class specifying the type of network it applies to. The latter
accomodates the needs of different addressing schemes, like
IP~addresses (the IN class), or addresses of Hesiod networks (used at
MIT), and a few more.  The prototypical resource record type is the A
record which associates a fully qualified domain name with an
IP~address.


\index{canonical hostname}
\index{hostname!canonical}
\index{alias!hostname}
Of course, a host may have more than one name. However, one of these
names must be identified as the official, or \emph{canonical host name},
while the others are simply aliases referring to the former. The
difference is that the canocical host name is the one with an A record
associated, while the others only have a record of type CNAME which
points to the canonical host name.


We will not go through all record types here, but save them for a later
chapter, but rather give you a brief example here.
Figure~\ref{intro.fig.hosts} shows a part of the domain database that is
loaded into the name servers for the \host{physics.groucho.edu} zone.


\begin{figure}[htbp]
\small
\begin{verbatim}
 ;
 ; Authoritative Information on physics.groucho.edu
 @                     IN    SOA          {
                      niels.physics.groucho.edu.
                      hostmaster.niels.physics.groucho.edu.
                      1034             ; serial no
                      360000           ; refresh
                      3600             ; retry
                      3600000          ; expire
                      3600             ; default ttl
                    }
 ;
 ; Name servers
                       IN    NS       niels
                       IN    NS       gauss.maths.groucho.edu.
 gauss.maths.groucho.edu. IN A        149.76.4.23
 ;
 ; Theoretical Physics (subnet 12)
 niels                 IN    A        149.76.12.1
                       IN    A        149.76.1.12
 nameserver            IN    CNAME    niels
 otto                  IN    A        149.76.12.2
 quark                 IN    A        149.76.12.4
 down                  IN    A        149.76.12.5
 strange               IN    A        149.76.12.6
 ...
 ; Collider Lab. (subnet 14)
 boson                 IN    A        149.76.14.1
 muon                  IN    A        149.76.14.7
 bogon                 IN    A        149.76.14.12
 ...
\end{verbatim}
 \caption{
  \label{intro.fig.hosts}
  An excerpt from the \file{named.hosts} file for the
  Physics Department.
 }
\end{figure}


\index{SOA (DNS record)}
\index{DNS!zone}
\index{authoritative name server}
\index{name server!authoritative}
\index{Start of Authority}
Apart from A and CNAME records, you can see a special record at the top
of the file, stretching several lines. This is the SOA resource record,
signalling the \emph{Start of Authority}, which holds general information
on the zone the server is authoritative for. This comprises, for
instance, the default time-to-live for all records.


Note that all names in the sample file that do not end with a dot should
be interpreted relative to the \host{groucho.edu} domain.  The special
name ``\host{@}'' used in the SOA record refers to the domain name by
itself.


We have seen above that the name servers for the \host{groucho.edu}
domain somehow have to know about the \host{physics} zone so that they
can point queries to their name servers. This is usually achieved by a
pair of records: the NS record that gives the server's FQDN, and
an A record associating an address with that name. Since these records
are what holds the name space together, they are frequently called the
\emph{glue records}.  They are the only instances of records where a
parent zone actually holds information on hosts in the subordinate zone.
The glue records pointing to the name servers for
\host{physics.groucho.edu} are shown in figure~\ref{intro.fig.nsptr}.


\begin{figure}[htbp]
\small
\begin{verbatim}
 ;
 ; Zone data for the groucho.edu zone.
 @                   IN       SOA          {
                      vax12.gcc.groucho.edu.
                      hostmaster.vax12.gcc.groucho.edu.
                      233              ; serial no
                      360000           ; refresh
                      3600             ; retry
                      3600000          ; expire
                      3600             ; default ttl
                    }
 ....
 ;
 ; Glue records for the physics.groucho.edu zone
 physics             IN     NS        niels.physics.groucho.edu.
                     IN     NS        gauss.maths.groucho.edu.
 niels.physics       IN     A         149.76.12.1
 gauss.maths         IN     A         149.76.4.23
 ...
\end{verbatim}
 \caption{
  \label{intro.fig.nsptr}
  An excerpt from the \file{named.hosts} file for GMU.
 }
\end{figure}


\subsection{Reverse Lookups}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.in-addr}
\index{DNS!reverse mapping|(}
\index{reverse mapping|(}
\index{looking up addresses}
\index{address!mapping to hostnames}
\index{hostname!obtaining from address}
\index{IP!address!and hostname}
\index{in-addr.arpa domain@\host{in-addr.arpa} domain}
\index{IP!network}

Beside looking up the IP~address belonging to a host, it is sometimes
desirable to find out the canonical host name corresponding to an
address.  This is called \emph{reverse mapping} and is used by several
network services to verify a client's identity. When using a single
\file{hosts} file, reverse lookups simply involve searching the file for
a host that owns the IP~address in question. With DNS, an exhaustive
search of the name space is out of the question, of course.  Instead, a
special domain, \host{in-addr.arpa}, has been created which contains the
IP~addresses of all hosts in a reverted dotted-quad notation. For
instance, an IP~address of \host{149.76.12.4} corresponds to the name
\host{4.12.76.149.in-addr.arpa}. The resource record type linking these
names to their canonical host names is PTR.


\index{DNS!zone}
\index{authoritative name server}
\index{name server!authoritative}
\index{delegating!DNS subdomains}
\index{creating!subnets}
\index{IP!subnet}
\index{subdomain (DNS)}
Creating a zone of authority usually means that its administrators are
given full control over how they assign addresses to names.  Since they
usually have one or more IP~networks or subnets at their hands, there's
a one-to-many mapping between DNS zones and IP~networks. The Physics
Department, for instance, comprises the subnets \host{149.76.8.0},
\host{149.76.12.0}, and \host{149.76.14.0}.


As a consequence, new zones in the \host{in-addr.arpa} domain have to be
created along with the \host{physics} zone and delegated to the network
administrators at the department: \host{8.76.149.in-addr.arpa},
\host{12.76.149.in-addr.arpa},  and \host{14.76.149.in-addr.arpa}.
Otherwise, installing a new host at the Collider Lab would require them
to contact their parent domain to have the new address entered into
their \host{in-addr.arpa} zone file.


The zone database for subnet 12 is shown in figure~\ref{intro.fig.subnet12}.
The corresponding glue records in the database of their parent zone is
shown in figure~\ref{intro.fig.groucho-rev}.


\begin{figure}[htbp]
\small
\begin{verbatim}
 ;
 ; the 12.76.149.in-addr.arpa domain.
 @                IN     SOA   {
                      niels.physics.groucho.edu.
                      hostmaster.niels.physics.groucho.edu.
                      233 360000 3600 3600000 3600
                    }
 2                IN     PTR       otto.physics.groucho.edu.
 4                IN     PTR       quark.physics.groucho.edu.
 5                IN     PTR       down.physics.groucho.edu.
 6                IN     PTR       strange.physics.groucho.edu.
\end{verbatim}
 \caption{
  \label{intro.fig.subnet12}
  An excerpt from the \file{named.rev} file for subnet 12.
 }
\end{figure}


\begin{figure}[htbp]
\small
\begin{verbatim}
 ;
 ; the 76.149.in-addr.arpa domain.
 @                   IN       SOA          {
                      vax12.gcc.groucho.edu.
                      hostmaster.vax12.gcc.groucho.edu.
                      233 360000 3600 3600000 3600
                    }
 ...
 ; subnet 4: Mathematics Dept.
 1.4              IN     PTR      sophus.maths.groucho.edu.
 17.4             IN     PTR      erdos.maths.groucho.edu.
 23.4             IN     PTR      gauss.maths.groucho.edu.
 ...
 ; subnet 12: Physics Dept, separate zone
 12               IN     NS       niels.physics.groucho.edu.
                  IN     NS       gauss.maths.groucho.edu.
 niels.physics.groucho.edu. IN  A 149.76.12.1
 gauss.maths.groucho.edu. IN  A   149.76.4.23
 ...
\end{verbatim}
 \caption{
  \label{intro.fig.groucho-rev}
  An excerpt from the \file{named.rev} file for network \host{149.76}.
 }
\end{figure}

\index{creating!DNS zones}
\index{DNS!creating zones}
One important consequence of this is that zones can only be created as
supersets of IP~networks, and, even more severe, that these network's
netmasks have to be on byte boundaries. All subnets at Groucho Marx
University have a netmask of \host{255.255.255.0}, whence an
\host{in-addr.arpa} zone could be created for each subnet. However, if
the netmask was \host{255.255.255.128} instead, creating zones for the
subnet \host{149.76.12.128} would be impossible, because there's no
way to tell DNS that the \host{12.76.149.in-addr.arpa} domain has been
split in two zones of authority, with host names ranging from \host{1}
through \host{127}, and \host{128} through \host{255}, respectively.

\index{DNS!reverse mapping|)}
\index{reverse mapping|)}
\index{DNS|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                             %%
%%              E N D   O F   C H A P T E R                    %%
%%                                                             %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
